Mass data conversions are sometimes necessary in application systems, such as enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, or supply chain management (SCM) systems. Typically, the affected data have to be converted using predefined rules.
For example, during a merger of two companies, several existing application systems may be merged. The new company needs to harmonize data from two different system landscapes that were created independently. Some examples of data conversion problems that typically arise in mergers are:
i) If document numbers for the new legal entity overlap in the two system landscapes, then the document numbers in one system landscape must be shifted into a number range that is disjoint from the document numbers in the other system landscape. To implement this, for example, in one of the system landscapes an offset is added to all the document numbers for that company code in all the relevant tables.
ii) Charts of accounts may be converted or the business year shifted in one system to match the business year in another system. For example, in one system the business year may start on January 1 and. in the other system on October 1.
iii) Material numbers may be changed, or currencies converted, such as during the introduction of the euro.
As these examples show, there are many reasons why mass data conversions may be needed. The data involved may include financial documents, change documents, material master data, text tables, and so on.
Some application systems, such as SAP R/3 based systems, support data conversion by, for example, generating a list of tables containing attributes to be converted and further generating a database view containing the attributes from the tables. The data for the view is then copied into a cluster table from where the application reads the data record by record through an appropriate application database interface and a SQL interface. Finally, the application performs the conversion, and then writes the converted data back to the database using again the application database interface and the SQL interface.
Other application systems, such as the Dayton Technologies ENC Billing Conversion system, generate a spool file including the data to be converted. A conversion program processes the spool file according to a conversion profile. After data validation, the conversion program creates a submission file that is submitted to an interface of a billing system that can handle the submission file.
In both implementations, multiple software layers and interfaces are involved in the data conversion process. Each interface is consuming time in the conversion process for routing the data to the next layer.
In some cases, a data conversion takes longer (e.g., more than a weekend) than a company can afford.